@taras this looks good to me. I have one suggestion though. From my experience, many users just have a single component definition which get different table instances passed in. Would it be simple to do something like the following:

new Table(column, rows, {
  rowComponent: 'myTableRow',
  spannedRowComponent: 'mySpannedRow'
});

I don't think we should be mixing the state and renderer.

We can do something like this:

{{light-table table rowComponent=(component 'my-table-row')}}

Although true, whats the difference between specifying a cellComponent and a rowComponent? Ideally, its the same concept. I just think that at this point, we are overloading the template. If you pass a component name via the table instance for rowComponent, all thats really needed inside that component is the table instance, the columns, and the actual row content. Everything else such as class names, bindings, etc, can be done on the component itself.

@offirgolan the same thing applies to cellComponent but cellComponent is existing API.

Passing cellComponent as a string is limiting API because it doesn't allow you to pass a closure component. Doing what I'm doing with rowComponent is not possible with the current implementation of cellComponent.

With that said, it would be difficult to implement cellComponent in the same way as rowComponent because there is no convention for creating columns in the template.

new Table(column, rows, {
  rowComponent: 'myTableRow',
  spannedRowComponent: 'mySpannedRow'
});

I'm not really sure what this offers. Why do you think this is a good idea?

@taras

new Table(column, rows, {
  rowComponent: 'myTableRow',
  spannedRowComponent: 'mySpannedRow'
});

I like this approach because of the following:

1. This allows you to declare a single table component that is fully dependent on the passed table instance which can also allow such declaration to be modular.
2. This keeps consistent with the current API. Currently, all custom table rendering is done via passed in table column properties. Your implementation now splits this declaration so you have to declare which components you want to use in multiple places.

As to what you were saying, I 100% understand your direction and I like as to where it's going but I dont feel like it is the appropriate time to change the structure / direction of the API. I think that we should either make all rendering decisions on the component declaration side OR on the table declaration side. Not both.

These 2 implementations are not actually equivalent. They're not just different APIs, they're actually different in their capability.

Closure component API allows to dynamically update the row when bound data changes. This is not possible with component string name API.

Yeah I guess that's true. Lets go ahead with this implementation. Hopefully in the near future we can delegate all renderer tasks to the template instead of the table instance (i.e. ember-microstates 😜).

Once documentation is added to the possible t.body components, feel free to merge!

@offirgolan do you want me to add the {{light-table table rowComponent=(component 'my-row')}}?